SIP is an application layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet phone call, multimedia distribution and multimedia conference, etc. As a foundational session control protocol, SIP is becoming one of the standards in telecom NGN and IT collaborative solution. SIP protocol is a lightweight, transmission layer independent and text-based protocol, and although it has the advantages of being simple, human-readable etc, it brings significant burden on server side processing. Therefore, how to improve SIP server performance has become an important research subject of many enterprises and organizations including IBM.
Generally speaking, performance will cover throughput, latency, and other QoS related parameters. Throughput and latency are especially the top parameters for measuring the performance of a server system.
In the SIP protocol, retransmission is a basic approach to achieve the reliability of setting up sessions, especially when messages are transmitted over a connectionless protocol such as UDP, and/or the SIP server is heavy loaded.
The main approach to implement the SIP retransmission is by starting a timer when a request is sent out (it is not necessary to start a timer for a message to which no response is expected). When no response is received before the timer fires, then this message will be retransmitted. The retransmitted request will be retransmitted again if still no response is received within another timeout period. Generally, the delay to send the second retransmission is longer than that of the first time, usually with a double value. If no response has been received as yet, the retransmission will be repeated until certain threshold is reached, for example, the 7th retransmission fails. Request sending is aborted (call fails) at this moment. For details about retransmission mechanism, refer to RFC3261.
Current study has shown that retransmission contributes a lot to the average call setup latency, and hurts the throughput greatly. For example, if a message has been transmitted 5 times before a response is received successfully, the delay for this session will be at least the sum of the timeout periods of the first 4 retransmissions, which can be several seconds, or even dozes of seconds. This value can be thousands times larger than the delay of a successful session setup without retransmission (the typical value is several milliseconds). Besides, although 5 messages have been transmitted over the network (5 times traffic), only one session is set up. Thus, the throughput measured by the session setup rate can be rather low, together with a low efficiency of network bandwidth utilization.
FIG. 1 shows schematically the sending and retransmission process of a SIP request (for example, INVITE). As shown, after the client sends an initial request such as INVITE, if no response is received from the server, then the request is retransmitted at 500 ms. If still no response is received, then a 2nd retransmission is performed, the delay of which is two times that of the 1st retransmission, i.e. 1000 ms. The delay of the 3rd retransmission is 2000 ms, and so forth. If a response is received after 5th retransmission, e.g. 200 OK message, then the whole call setup latency is approximately the sum of the previous retransmission delays, that is, 15500 ms. This time is far greater than the call setup time without retransmission, generally several milliseconds.
In prior art, logically there is a queue on the SIP server side (since several queues or part of them can be seen as one queue) which does not know whether a message is a new request or a retransmission, or any other attributes of the message. Such a queue can be found in the TCP/IP stack, or in the java SIP stack which will be shipped with WAS. It should be noted that, the java SIP stack is modeled as having a queue with infinite capacity.
Since this queue cannot distinguish between a retransmitted request and a new request, the retransmitted request will just be treated as if it were also a new one. This “fair” processing will lead to performance penalty for the server.
Currently, there is work that attempts to remove redundant retransmissions on SIP proxy/server side, and there is also work that attempts to implement complicated classifier to achieve higher QoS for heavy-loaded SIP proxy/servers. However, these works have not distinguished between new SIP requests and retransmitted SIP requests and performed corresponding processing respectively, so they have not overcome the problems of SIP server throughput and latency.
Apparently, there is a need for a method and apparatus for improving the SIP server performance through dynamically classifying and scheduling SIP request packets.